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Abstract 

Program synthesis for critical applications has become a viable alternative to program 
verification. We use nested resolution and its extension to synthesize a set of sorting pro- 
grams from their first order logic specifications. We have successfully synthesized a set of 
sorting programs, such as, naive sort, merge sort, and insertion sort, starting from the same 
set of specifications. 


1 Introduction 

The important phases of a software life cycle include requirement acquisition, development of 
algorithms, implementation, verification and maintenance. Usually, the execution performance 
is an expected requirement in a software development process. Unfortunately, the verification 
and the maintenance of programs are the time consuming and the frustrating aspects of software 
engineering. The verification can not be wavered for the programs used for critical applications 
such as, military, space, and nuclear plants. As a consequence, synthesis of programs from 
specifications, an alternative way of developing correct programs, is becoming popular. 

There are three basic approaches for program synthesis: theorem proving [5, 6, 8], program 
transformation [1, 2] and problem solving [3]. In the theorem proving approach, a target 
program is constructed incrementally at each step of the proof whereas in the transformational 
approach, inference rules and transformation rules are applied to the specifications and to the 
derived sentences until the target program is realized. Synthesis systems based on problem 
solving methods are inflexible as compared to the other two methods. However, they tend to 
be very effective in the domain in which they operate 

In this paper, we do not concern ourselves with the problem acquisition phase of automatic 
programming. Specification acquisition and subsequent refinement is a research problem in its 
own right. Assuming that the program is specified in first-order predicate logic, we describe 
the derivation of logic programs for sorting. In section 2, we provide a. brief review of nested 


403 


PRECEDING PAGE BLANK NOT FILMED 


resolution and its application to program synthesis. In Section 3, we describe the specification 
and the derivation of sorting programs, and it is followed by a summary and discussion. 


2 A review of nested resolution and its application to program 
synthesis 

We start with some notations. Let /’[/’] denote a well-formed formula (wff) containing one or 
more occurrences of a sub-wff P. Then, a new wff obtained by replacing all occurrences of P by 
Q is denoted by F[P/Q]. 

We give an informal definition of polarity. For a rigorous definition the reader may refer to 
[7, 5]. A sub-wff P has a positive (negative) polarity in F[P ] if and only if (iff) P occurs within 
an even (odd) number of explicit or implicit negations. The positive polarity and the negative 
polarity are written as i ? [T >+ ] and F[P~], respectively. If P occurs within an equivalence 
connective or within the if clause of an if-then-else connective, then P has a positive-negative 
polarity and is written as FIP* ]• 

2.1 Inference Rules 

We [4] have proposed nested resolution [9] and its extension for logic program synthesis from 
first-order specifications. The nested resolution is a variation of nonclausal resolutions. The 
reader may refer to [9] for more details. Inference rules are applied to a pair of statements: a 
statement to be transformed which we call a transformee, and a statement used for transforma- 
tion which we call a transformer. The transformer may be an axiom, a transformation rule or 
a lemma. The transformee is initially an axiom from the specification set, and subsequently, it 
may be the result of an earlier transformation or a lemma. In every transformation, a sub-wff 
of the transformee is replaced by another sub-wff that is determined by the transformer. 

F[P + ] T[P-] 

G[P'} G\P'] 

F[P+6/ G9[P'9/true ]] F[p-0/-,G9[P'0/ false}} 


Where 0 is the most general unifier (m.g.u.) of P and P' . That is P9 = P'9. Here the wffs 
F and G are the transformee and the transformer, respectively. 

Let us consider an example to explain the inference rule. 

P{X,Y) A Q(Y, Z ) R(X, Z) 

S{X',Y') -* P{X',Y') 

~ [ (S(X, Y) -+ false ) A Q(Y, Z) - R(X, Z) 

Where 9 is {X'/X, Y’/Y}. The expression can be simplified to 5(X,y) A Q(Y , Z) — > R(X, Z) 
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2.1.1 Some special cases 


Here we describe some special cases of nested resolution. These rules are handy when deriving 
programs by hand. To use these rules, polarities of the transformer and the transformee should 
be followed strictly. 

F[P+] F[P~ ] F[P] 

P f ~ P'+ P f Q' 

F[P+0/ false] F[P~0/true] F[P9/Q 9 0] 

where 6 is the m.g.u. of P and P 9 . 

2*2 Inference rules in the presence of explicit quantifications 

In refutation proof procedures, an existential quantifier is replaced by either a Skolem constant 
or a Skolem function. Replacing an existentially quantified variable by a Skolem constant or a 
Skolem function is not acceptable in transformational program synthesis methods [4] because 
we will lose some valuable information in the course of that replacement. To overcome the 
problem, we extend the nested resolution to handle quantified wffs. To avoid inadvertent 
problems during unification, all variables in both the transformer and the transformee are 
renamed at each step. The following condition that checks for possible scoping violations must 
be satisfied when existentially quantified variables are unified. 

Condition QS: (Quantified variable Substitution) 

• An existentially quantified variable, say X , within the scope of a universally quantified 
variable, say Y, cannot be unified to the same universally quantified variable. (That is, X 
cannot be unified with Y. This is usually detected by occur check in Skolemized version 
of the quantified wffs) 

• Two existentially quantified variables cannot be unified. 

Example 

VX 3 Y P(X,Y) 

P(X\X')-+Q(X') 


X f is unified to X but we cannot unify X with Y since it violates the QS-condition. 

The extension to the nested resolution for quantified wffs are given as following: 

1. If the transformer is quantifier free and the transformee has an existentially quantified 
variable then the nested resolution is applied in the same way as it is applied to the 
quantifier free case, provided that the condition QS is not violated during unification. 
Consider an example 
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3 Y VX P(X, Y) V R(X,Y) 
P{X',Y') Q(X',F') 


3F VX (trt*e-»Q(X,F))V P(X,F) 

which simplifies to 3F VX Q(X, F) V R(X,Y) 

2. If the transformee is quantifier free and the transformer has an existentially quantified 
variable then the nested resolution is applied in the same way as it is applied to the 
quantifier free case, provided that the condition QS is not violated. Consider an example. 

P{X,Y,Y) — > Q(X,Y,Y) 

VX' 3F' VZ' P(X', Y', Z ') V R(X', F', Z') 


VX 3 Y {-.{false V R{X',Y',Y')) 

—* Q(X', Y', F')) 

which simplifies to VX 3F P(X, F, F)V Q(X,Y,Y) 

3. When the transformer and the transformee have existential quantified variables, the ex- 
tension to the nested resolution becomes complicated. Since, such case is not common in 
program synthesis, it is not considered here. 

Transformation Rules 

Transformation rules are usually second-order wffs which have variable predicates. These 
rules are used to simplify derived sentences or specifications. We provide some of the transfor- 
mation rules used in this paper. 


P «-► P 

Pi V P 2 V P 3 «- P 3 


2.3 Organization of Derivations 

As indicated earlier, the specification consists of a set of statements in first-order logic. The 
synthesis system transforms these statements into a set of Horn clauses that constitute an 
executable program. At each step of the derivation, the transformee and the transformer state- 
ments interact to produce a result. Initially, the transformee is one of the statements from 
the specification set; later the transformee is one of the intermediate results of the derivation. 
The transformer can be a statement from the specification set, an intermediate result, a trans- 
formation rule or a simplification rule. Simplification rules may have predicate variables, in 
which case higher-order unification is assumed. In our derivations all the transformees and 
the transformers are shown at the left and the right hand sides respectively. The sub-wff of 
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the transformee to be transformed is underlined while the sub-wff of the transformer that is 
used for transformation is overlined. After the nested resolution is applied to each transformee 
and transformer pair, the resulting wff is simplified and only the simplified w'ff is shown in the 
derivation. 

2.4 Controlling the Inference 

Logic program synthesis may be viewed as a process that creates executable Horn clauses for 
each predicate appearing in the specification. This view forms the basis of our strategy and 
provides a mean for detecting missing knowledge in the specification. We arrange the predicates 
appearing in the specification in the order in which the executable Horn procedures arc derived. 
The derivation starts with the first predicate and continues till the end of the list. Once we have 
derived all the executable Horn clauses for all the predicates in the list, the synthesis completes 
successfully. 

It is well known that all the first order sentences cannot be transformed into Horn Logic. 
However, a procedure which is not in Horn Logic can be transformed into an executable Horn 
clause form either by introducing recursion or by interpreting negation as failure. This is why 
we were able to transform the first order specifications into an executable Horn clauses. 

We use the following procedure to control the derivation. 

1. For each Predicate P appearing in the specification do the following. 

(a) For each, if half of the definition of P, do the following: 

i. If the body has a universal quantifier, select a literal within the scope of the 
quantifier such that there exists a transformation that will enable us to apply 
induction and hence introduce the recursion. Introduction of recursion will usu- 
ally transform a non-Horn clause into a Horn clause. Then establish the base 
case for the induction using ground terms of the body. 

ii. Check whether the Horn clause is executable. If not, transform the literals of 
the body until an executable Horn clause form is obtained. 

From the if and only if definition of a predicate P, we can easily obtain the if half of the 
definition. That is, from P <-► body we can get P <— body. If we have disjunctive literals as the 
head of the if half, then interpreting negation as failure, we can obtain the if half of P. That is, 
from P V Q <— body we obtain P +— notQ , body. 

3 Specification and Derivation of Sorting Programs 

In this section we provide specifications for sorting program and derive different sorting pro- 
grams starting from the same specifications. Let us define a relation sort(x,y) which holds when 
y is a sorted permutation of x . The corresponding specifications are 

sort(x , y) perm{x , y), ordered(y) 
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perm(x , y) *-* 'du3z(occurs(u, z, a;) <-> occur s(u , y )) 
ordered{y) <-»■ VuVv(precedes(u, v, y) —* u < v) 

The second statement is interpreted as stating that y is a permutation of x, if for every element 
u, x and y contain exactly the same number of occurrences of u. The third statement specifies 
the ordered relation, y is ordered if and only if, for every two elements u and v in y, if u 
precedes v in the list, then u is less than or equal to v in magnitude. 

The following statements specify the occurs relation. 
occurs(u, z , nil) «-» z = 0 

(occur s(u,z, x)<r+ occur s(u,z x ,Xi), occur s(u,z 2 , x 2 ),zi + z 2 = z) 

<— union(x-i, x 2 , x) 

According to the first statement, the empty list contains no occurrences of u and according the 
second statement, if x can be split up into two subsets Xj and x 2 , then the total number of 
occurrences of u will remain the same. An element u precedes an element v in the list x if it 
occurs before t) in r. The precedes relation is specified as 

- \precedes(u , v , nil ) 

-<precedes(u, v, x.nil) 

( precedes(u , v,x) *-* precedes(u, v, xi) V precedes(u , v, x 2 ) V ( u£ xi,v£ x 2 )) 

4— append(xi, x 2 , x) 

The first two statements indicate when the precedes relation cannot hold. In the third state- 
ment, the list is broken down into two sublists and the relation recursively applied to these 
sublists. If u precedes r in i, then it must precede it in either of the sublists if both u and v 
are in that sublist. Otherwise, u is in the first sublist and v is in the second sublist. 

We have used the relations union and append and have not indicated how these are defined 
and how they differ. The relation union is not the same as the union operation on sets. The 
result x of a union operation on lists x and y may contain duplicate elements. Thus the relation 
uni on(a. nil, a. nil, a. nil) does not hold whereas union(a.nil,a.nil,a.a.nil) does. The relation 
append is the familiar list append relation. The difference between union and append is that 
append respects the order of the elements of the appended lists, whereas union(x, y, z) just says 
that z is a permutation of the result of appending x and y. We do not explicitly specify these 
familiar relations, but instead use their properties which are listed below. 

append(nil , y, y) 

append(u.x,y,u.z ) 4 — append(x , y , z) 
union(x, y, z) <— append(x , y, z ) 
union(x , y, z) 4— union(y, x,z) 
union(u.x , y, u.z) 4 — union(x, y, z) 

From these properties, we can easily derive the following statements as lemmas. 

append(u.nil , y , u.y) 
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union(u.nil , y, u.y) 
union(nil, y, y) 

umon(x, u.y, u. 2 ) <— union(x, y , 2 ) 

We are now ready to tackle program derivations. We begin with programs and lemmas for 
perm and ordered . 

1 . perm(x , y) <-> Vu3,g( occurg(u, 2 , a:) ^ occurs(u, 2 , y)) 

occur,$(u, 2 , m7) <-+ 2 = 0 

2. perm(nil , y) «-> Vu32(2 = 0 <-+ occur,s(u, 2 , y)^ _^) 

occurs(u, 2 , m7) 2 = 0 

3. perm(nil , n?7) «-► Vu32(2 = 0 2 = 0) 

4. perm(nil, nil) 

This forms a Horn clause for the trivial case when the input list is empty. The following useful 
lemma on perm(x,y) is assumed. For the derivation of this lemma see [10]. 

1. perm{x , y) union{x u x 2 , x), perm(xi, yi), perm(x 2 , jfe), tmion(yi, t/ 2 , y) 

With appropriate procedures for union, this can be used as a Horn clause procedure for perm . 
We now derive a few lemmas. 

1 . perm(x,y) <— Vu32( occur.s(u, 2 , x) <-> occur.s(u, 2 , y) ^_^) 

P~P 

2. perm( x,x) 

This lemma comes in handy when we want to eliminate extra terms by unifying them. The 
following lemma is used when attempting to unify elements within lists. 

1. perm(x, y) <— umon(xi, X 2 , x)^ y 

perm(xi,yi),perm(x 2 , V 2 ), union(yi, y)^ ^ 

union(u.nil,y, u.y ) 

2. perm(u.x, v.y) <— perm(u.nil, mnil) ,perm(x, p) 

perm(x , x) 

3. perm(u.x,u.y) <— perm(x,y) 

Other results that we use are 

(ue x «-*• u€ y) — perm(x, y) 
perm(x, y) *— perm(x, l),perm(l,y) 

These statements cannot be derived from our specifications for perm. They can be derived if 
we use different specifications, but then the other derivations become more difficult. We prefer 
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to pay the price and assume these statements as axioms rather than derive them as lemmas. 
The results of the derivations and the axioms for perm used in the sequel are listed below. 

perm(nil, nil ) 
perm(x, x) 

perm(u.x , u.y) <— perm(x , y) 

perm(x, y ) <- union{x 1 , x 2 , x),perm(x 1 ,y 1 ),perm(x 2 , y 2 ), union(y u y 2 , y) 

(uE x uE y) perm(x , y) 

perm(x , 2/) perm(x, /), perm(Z, y) 

We now proceed to the derivation of programs and lemmas for ordered. 

1. ordered(y) <— WVi;(precede,s(u, y)^ » u < u) 

~iprecedes( / u, u, m/) 

2 . ordered(nil) 

1. ordere<i(y) <— V uiv{precedes{u , v, — i ► ix < v) 

-I precedes(u, v, x.nil) 

2. ordered(x.m7) 

These two Horn clauses can be regarded as procedures for the trivial cases. 

1. ordered(y) *— 'iu'iv(precedes(u, v, y) — ► u < t?) 

(precede,s(u, u, x) +-> precedes(u, v, xi) V precedes(u , u, X2) 

V (uE ari, v£ x 2 )) 

<— append{x\,X 2 ,x) 

2. ordered(y) VuVt>((precedes(i£, v, yi) V precedes(u, v, y 2 ) V (w6 j/i, vE t/ 2 )) 

- + « < v),append(yi,y 2 ,y) 

3. ordered(y) <— 

\/uVv(precedes(u , v, yi) — * u < v) , 

VuVn(precedes(u, v, y 2 ) —* ► w < v) 

VmVu((u€ yi,t?€ 3/2) -► « < v),append(yi,y 2 ,y) 

ordered(y) ^iuiv{precedes{u , v, y) — ► ft < n) 

4. ordered(y) 4 — ordered(yi), ordered^), 

Vt Nv({u£ y x ,ve y 2 ) -► u < v) y append(y 1 ,y 2 ,y) 

This statement is used later on, in derivations for sort and also as the starting point in the 
following derivation. 

1. ordered(y) <— ordered(y\),ordered(y 2 ), 

VuVt;((ue yjyve y 2 ) -* u < v), appendfyj ,y 2 ,y) 

formation of procedure lessall 
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2. ordered(y) <— ordered^), ordered^), les$all{y\, y 2 )> <Wend(yi, y 2 , 2/) 

3. /es,sa//(x, y) <-► VuVu((uE a:, i’E y) — * u < i?) 

The relation lessall(x , y) holds if all the elements in list £ are less than or equal to all elements 
in list y. We will derive programs and lemmas for lessall shortly. 

1. ordered{y) <— ordered(y\),ordered{y 2 )'> 

VuVv(ue yi,«e y 2 -► te < u), appendix, y 2 ,y) ( } 

append(u.m7, v, u.v) 

2. ordered(x.y 2 ) ordered(x.m7),ordere<f(y 2 ), 

VuVu(uE x.nil, vE y 2 u < v) 

3. ordered(x.y 2 ) ordered(x.nil), ordered (y 2 ), 

Vu(uE y 2 -+ x < v) 

formation of procedure lessall* 

4. ordered(x.y 2 ) orcfered(x.m7)^, orderecf(y 2 ), lessall f (x, y 2 ) 

5. ordered(x .y 2 ) <— orderecf(y 2 ), lessall *(x, y 2 ) 

ordered{ x.nil ) 

We will use lessall' in the derivations for lessall. It is defined as 
lessall* {x , y) <-+ \/v(vE y — ► x < u) 

The useful statements that we have derived about the ordered relation are 


ordered(nil) 

ordered(x.nil) 

ordered(x) <— ordered(xx), or7ered(x 2 ), 

V^Vu(uE Xi, vE x 2 — > u < u), appencf(xi, x 2 , x) 
ordererf(x) <— ordered(xx), ordered(x 2 ), /essa//(xi, x 2 ), append(xi, x 2 , x) 
orderee/(x.y) <— ordered(y), lessall 9 (x , y) 

We still have to derive a few procedures and lemmas for lessall * and lessall . We begin with 
lessall. 


1. /essa//(x, y) <— VuVidf iiE X( g+ ), uE y) — > u < u) 

2. lessall{nil, y) 

3. lessall(x , y) <— VuVu((tzE x, vEj/^ + j) — ► u < t>) 

4. lessall(x,nil) 

These are the base case procedures for lessall. 

1. lessall(x , y) <— VuVuff uE X( ?j ^ i;E y) — ► u < v) 


-niE nil 


-nzE m7 
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nE v.y u = v V uE y 

2 . lessall(z.x', y) <- VuVv(((u = z V uE x'), uE y) -> u < v) 

3. lessal^z.x' ,y) <— 

VuVv(u — z , ve y —► u < u), 

VuVu(-uE x 7 , vE y — * ► u < v) 

4. /essa//(z.x 7 , y) 

Vv(ve y -> z < v) T 
VuVu(tzE x\ v(z y —+ u < v) 

lessall f {u,x) <-► Vv(ve x —> u < v) 

5. lessall(z.x' , y) <— lessall \z, y ), 

VuVu(uE x 7 , uE y — ► w < ^ 

/essa//(x, y) <— VuVx;(uE x,vEy-^«<u) 

6. lessall(z.x\y) <- lessall '{z, y), /essa//(x', y) 

This statement can be used as a procedure for lessall. We now proceed with the derivation of 
lemmas. 

1. lessall(x, y) <— VuVu((uE x, uE y ^_^) -> u < v) 

(uE z <-► u(z Z\ V uE 2 ^ 2 ) < — UTiion(zi , Z 2 , z) 

2. lessall(x , y) <— VuVt;(uE (vE yi V vE y 2 ) — ► u < t?), rmio7?(yi, y 2 , y) 

3. lessall(x , y) <— 

VuVu(uE i?E yi tt < ^ 

V^Vi;(tfg x, vg y 2 — > ^ < u) ( ,^nzQ7i(y 1 ,y 2 , y) 

lessall{x,y) <-► VuVv((wE x, vE y ) — * w < v) 

4. lessall(x , y) *— lessall(x, y x ), lessall(x , y 2 ), ttmcm(yi, y 2 , y)^ ^ 

union(v.nil, u, u.w) 

5. lessall(x , u.y 2 ) lessall(x , u.m7), /es,sa//(x, y 2 ) 

Next, we derive a lemma that states that the lessall relation is not changed by permuting x or 
2 /* 

1. lessall(x, y) <- VuVu((uE x, t;Ey ( ?)) ) -► u < v) 

(«E x *-► ^E y) +— perm(y , x) 

2. lessall(x , y) <— VwVt;((tt£ L x^ + j, vE z) — ► w < n),perm(z, y) 

(uE £ <-+ uE y) <— perm(y, x) 

3. /essa//(x, y) <— VuVt;((uE tu,^E z) — > u < 17 )^ yperm(z , y), perm(tn ? x) 

/e^^a//(x, y) ^ VuVv((uE x, vE y ) — ► ^ < v) 

4. lessall(x , y) <— /essa//(u;, z),perra( 2 r, y), perm(in, x) 
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Another lemma that can be derived for lessall lets us exploit the transitivity property of lessall. 

lessall(x, y) <— lessall(x , z),lessall(z , y ) 

We now begin on the derivations of programs and lemmas for lessall' . 

1. lessall'(x, y) <— Vu( g€ 3/ ( 7+ ) x < v) 

-itiG nil 

2. lessall '(x, nil) 

This forms the base case procedure for lessall'. 

1. lessall '(x, y) <— Vv( v6 y ^ q+ ^ — 1 2 3 • x < v) 

u£ v.y <-+ u — v V uG y 

2. lessall ’(x, u.y ') <— Vw(u = u V t?G y' — ► x < v) 

3. lessall 1 (x, u.y') <— Vu(v = u —> x < v),Vv(v€ y' — > x < u) 

4. lessall 1 (x, u.y') <— x < u, Vu(uG t/ — » a? < 

lessall'(x , ?/) <— Vt>(vG y — 1 " 3: < v) 

5. lessall '(x, u.y 1 ) «— x < u, lessall \x,y') 

This clause along with the base case derived earlier can be used as procedures for lessall'. We 
proceed with the derivation of lemmas for lessall'. 

1. lessall' {x , y) <— Vufug y -» x < 

u < v u < iu,w <■ v 

2. lessall '(x, y) <— Vu(ug y -» w < t?) a; < in 

lessall '( x , y) Vu(uG y — + a; < v) 

3. lessall r (x, y) <— lessall '(w, y),x < w 

We now derive a lemma that links lessall' with ordered. 


5 . 

6 . 


ordered(y) *-> VuV»( precede.s(u, u, y) u < v) 

( precedes(u , r, x) «-► precedes(u , v, xj) V precedes(u, v, x 2 ) 

V (uG xj, ug x 2 )) 
<— append(xj,x 2, x) 

(ordered(y) *-* VuVv((precedes(u , u, 3/1 ) V precedes(u, v , y 2 ) V («G 2/1, v£ y 2 )) 

—> u < v)) <— append(yi ,y 2 ,y) 

(ordered(y) — ► 

VnVu( (precedes(u, v, yi) V precede.s(M, u, y 2 ) V (ng 


— ► u < u)) <— append(yi,y 2 ,y ) 


(Pa V P 2 V P 3 ) - P 3 
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7. (ordered(y) — ► WVu((«G j/i, vG y 2 ) — ► « < v)) <— append(yi, y 2 , y)^ ^ 

appencf(u.m7, v, tt.u) 

8. ordered(x.y') — ► VuVu((uG x.m7, uG y') — ► u < v) 

9. ordered(x.y') — ► Vi>((i;G y r ) — ► x < v ) 

lessall \x , y) <-+ Vu(uG y — s ► a: < u) 

10. 0rdered(x.y') — ► lessall f (x , y') 
which can be rewritten as 

lessall f (x^y f ) <— orcZered(x.y / ) 

We use the previous two lemmas in the proof of the next lemma. 

1. lessall \x , y) «— lessall f (w,y ) , x < u> 

lessall '(x , y') <— ordered(x .y r ) 

2. lessall '( x , y) <— ordered(u;.y), x < tu 

We have only a couple more lemmas to go before starting with actual sorting programs. 

1. lessall\x , y) <— Vu( ug y (? f ) — ► x < v) 

(uE x <-> uE y) <— perm(y y x) 

2. /essaZ/^x, y) Vu(t?G £ — » x < u) ypcrm(z y y) 

lessall '(x, y) <-► \/v(vE y — » x < u) 

3. lessall ; (x, y) <— lessall \x , z),perm(z, y) 

And the last lemma is just as simple. 

1. lessall '(x , y) <— Vv(v€jy^ + j — ► x < v) 

O^Ty <-► (vG yi V uG y 2 )) <- tmion(yi,y 2 ,y) 

2. lessall '(x, y) Vu(uG yi — ► x < u) , 

Vvjve V 2 -> a < v) ( )? ^nzon(yi , y 2 , y) 

lessall f (x, y) <-> Vu(uG y — > - x < v) 

3. lessall ; (x, y ) «— lessall 7 (x, yi), /essa/Z^x, y 2 ), union(y 1 , y 2 , y) 

The complete set of programs and lemmas for lessall and lessall ' are 

lessall(nil , x) 
lessall(x , mZ) 

ZessaZZ(u.x, y) <— lessall\u , y), ZessaZ/(x, y) 
lessall(x , u.y) <— /es,saZZ(x, u.m/), Zes,sa//(x, y) 
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lessall(x, y) <— lessall(w, z),perm(w,x),perm(z>y) 
lessall(x, y) <— lessall(x , z),lessall(z,y) 

lessall' (x, nil) 

lessall'(x , u.y) 4— a: < u, lessall'(x , y) 

lessall f (x , y) 4— lessall f (w , y), a: < iu 

lessalV(x , y) 4— ordered(x.y) 

lessall' (x , y) 4— ordered(w.y), a: < 

lessall'(x,y) 4— Zessa//'(x,x),perm(2,y) 

lessall' (x,y) 4 - lessall '(x, yi), lessall(x , y 2 ), union(yi, y 2 , y) 

3*1 Naive Sort 

We now have enough material to start the derivation of sorting programs. In fact, we have 
enough to actually build a naive sort program which is given by 

soH(x, y) 4— perm(x, y), ordered(y) 
perm(m 7 , m/) 

perm(x, y) 4— umon(xi , x 2 , x),perm(xi, yi), perm(x 2 , y 2 ), tmion(yi, y 2 , y) 

ordered(nil) 

ordered(u.m 7 ) 

ordered(x) 4— append(xi, x 2 , x), lessall(x 1, x 2 ), 
ordered(xi), ordered(x 2 ) 

together with the procedures already derived for lessall and procedures for union and append. 

In the following section, we will derive a program for merge sort, which can be further 
transformed into a program for insertion sort. Following that we derive a program for quicksort 
which is further transformed into a program for selection sort. A lemma which can be quite 
easily proved from the specifications for the sort relation is 

(sort(x, y) 4-+ perm(x, y)) 4— ordered(y) 

We can also easily derive the following base cases for sort from its specifications and from the 
lemmas already derived. 

sort(nil , nil ) 
sort(u.nil , u.nil) 
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3.2 Merge Sort 

The merge sort derivation starts off with the usual definition of sort. 


1. sort{x, y) perm(x, y)^ , ordered(y) 

perm(x, y) <— perm(x , z), perm(z, y) 

2 . sort(x, y) 4— perm(x, z)^ y per m(z,y), order ed{y) 

perm(x, y) 4 — union(xi , x 2 , x),perm(xx, y x ), 
perm(x 2 , y 2 ), wmon(y a , y 2 , 2 /) 

3. sort(x , y) 4 — t*mon(xi, x 2 , x), perm(xi, zi) , 

yerm(x 2 , tmton(zi, £ 2 ? z),perm(z, y), ordered(y) 

perm(x, y) 4 — sort(x , y) 

4. sor£(x, y) 4 — «mon(a?i, x 2 , x), <sorZ(xi, 2 q), sor£(x 2 , 2 : 2 ), 

union(z \ , z 2 , 2 ), perra(z, y), ordered(y ) 

formation of procedure merge 

5. sor£(x, y) 4 — tmton(xi, x 2 , x), S077 (xi, Zi), sorf(x 2 , z 2 ), merge(zi, z 2 , y) 

6. merge{z\,z 2 , y) 3z(unum(zi, z 2 , z),perm(z, y),ordered(y)) 

The derivation of the merge procedure is a little harder since we have to consider more cases. 

1. merge(z\, z 2 ,y) <— 3z(tmum(zi, z 2 , z),perm(z, y),ordered(y)) 

deletion of existential quantifier 

2. merge{z \ , z 2 , y) <— imum(zi, z 2 , z) yperm(z , y),ordereti(y) 

um'on(m'{, y, y) 

3. merge(nil , y, y) 4 — perm(y , y) , ordered(y) 

perra(x, x) 

4. merye(m7, y, y) 4 — ordered(y) 

Similarly, we can derive the Horn clause 

raerye(x, m/, x) 4 — ordered(x) 

We now proceed with the derivation of a procedure for merge , assuming that the first pair of 
terms of merge are already sorted, and taking into account the fact that the lists to be merged 
are not empty 

1. merge(u.Zi y v.z 2 , y) 4 — z3z(i/n7on(u.zi , n.z 2 , z), perm(z , y), ordered(y)) 

deletion of existential quantifier 

2. merge(u.z\,v.z 2 ,y) 4 — umon^.Z!, u.z 2 , z) ) ,perm(z, y), ordered(y) 

umon(n.x, y, u.z) <— umon(x, y, z) 
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3. merge(u.Z\,v.Z 2 , y) «- tmtonf^tn^s^ permCtt./.y^ yOrdered(y) 

perm(u.x , u.y ) <— perm(x, y) 

4. merge{u.zi,v.Z 2 ,u.y') +- umon(zi,u.z 2 , ApermC^y^ orderedtu.y^ ) 

ordered(u.x) <— ordered(x), lessall'(u, y) 

5. merge(u.zi, V.Z 2 , u.y') <— union(zi , v.z 2 , z r )> perm(z , y ), ordered(y ), lessall^ (u, y ^ 

lessall'(u,x ) <— lessall '(u,z),perm(z,x) 

6. merge(u.zi,v.Z2,u.y') <- tmion(zi, u.z 2 , z'), perm(z', y r ) , order ed(y'), 

lessall'(u, z), perra(z, y') 

perm(x, y) <— perm(x, y), perm(x y) 

7. merge(u.zi,v.Z2,u.y') <— union(z\,v.Z 2 , z'),perm(z' ,y'),ordered(y ), lessall^ (u, z ^ 

le$sall'{x,y) <- lessall' {x, j/i), lessall'(x , y 2 ), imion(yi, y 2 , J/) 

8. merge(u.z 1 ,v.z 2 ,u.y l ) <- unionjzi , u.z 2 , z') , permjz', y'), orderedjy'), 

lessall '(u, yi), lessall '(u, y 2 ), union^u y 2 , z') 

wnion(xi, x 2 , y) <— union(xi,x 2 ,y),union(y 1 ,y 2 ,y) 

9. merge{u.z \ , u.z 2 , u.y*) union(zx ,v.z 2 , z , ), perm(z , y ), ordered(y ), 

lessall '(u, zi), lessaU '(it, u.z 2 ) ._ ^ 

lessall '( x , u.y) *— x < u 

10. merge(u.z\ , u.z 2 , u.$/) <— union(zi, v.z 2 , 

perm(z' ,y'),ordered(y'),lessall'(u, Zi),u < u 

Introduction of existential quantifier 

11. Tnerge(u.Zi, v.z 2 , u.y 1 ) «— 

3z'(union(zi, u.z 2 , z'), 

perm(z ; , y'), ordered(y / ))^ , lessall '(u , z x ), u < v 

merge(zi, z 2 ,y) <-► 3z(union(zi, z 2 , z)), 
perm(z, y), ordered(y)) 

12. merge(u.zi,v.z 2 ,u.y') <— mergejzi, v.z 2 , y'), /essa//'(u, z x ) , u < v 

lessall '{u,Z\) 

13. merge(u.zi,v.z 2 ,u.y') <— merge(z\,v.z 2 ,y'),u < v 

The other Horn clause for merye can be similarly derived and has the same form. 

merge(u.zi,v.z 2 ,v.y') <— merye(u.Zi, Z2,y'),lessall'(v, z 2 ),v < u 

The complete sort program for merge sort is 

sort(nil , nt/) 
sort(u.nil, u.nil) 

sort(x , y) <— umon(x x , i 2 , z), sort(xi, Zi), sort(x 2 , z 2 ), merge(z x , z 2 , y) 
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merge(nil,y,y) 
merge(x y nil , x ) 

merge(u.Zi, i ).z 2 ,u.y) u < u, lessall f (u, z\), merge{z\, v.z 2y y) 

merge(u.zi , u.z 2 , ^-y) v < u, lessall f (v , z 2 ), merye(u.Z!, z 2 , 2/) 

3.3 Insertion Sort 

The above program for merge sort can be modified a little in order to make it an insertion sort 
program. In an insertion sort, the first element of the list is removed, the rest of the list is 
sorted and then the first element is reinserted into the list in the right place without upsetting 
the ordering. 

1. sort(x y y) <- union(xi,x 2 ,x)^ ,sort(x u *i), sort(x 2 , z 2 ), merge(z u z 2 , y) 

union(v.nil y y , v.y ) 

2. y) sor7(t>.m/, Zj) ^ , sort(x, z 2 ), merge(z\, z 2 , y) 

sort(u.nil , u.m7) 

3. sortfo.s, y) <— sort(x, z 2 ), merge(u.m/, z 2 , y)^ 

Formation of new procedure insert 

4. sort(v,x , y) <— sorf(x, z 2 ), insert(i?, z 2 , y) 

5. m5er/(u, z, y) <-► merge(y.nil , z, y) 

We now derive procedures for insert. 

1. 2 *n,sert(u, z, y) <-► merge(v .m/, z, y) 

merye(x, nil , x) 

2. m,seri(u, m7, v.m7) 

This forms the base case procedure for mser/. 

1. mser*(v, z, y) <— merge(v.nil , z, y)^ ^ 

merge(u.zi,v.z 2y u.y) <— u < v, merge{z\ , v.z 2 , y) 

2. 2 nsert(u, x.z', u.y') u < x, merge(nil , x.z', y')^ ^ 

merye(m7, y, y) 

3. inser£(t;, x.z', t\x.z') <— u < x 

Similarly, we can derive the other Horn clause for insert. 

insert(v y x.z , x.z') <— x < v, insert(v, z, z') 

The complete insertion sort program is 
sort(nil, nil ) 
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sort(u.nil , u.nil) 

sort(v.x , j/) <— sor/(a;, z), m«serJ(v, z, ?/) 

insert, m7, v.nil) 

insert(v , z.z, v.x.z) <— u < x 

znser^v, a\z, z.z') <— a: < u, insert(v , z, z ; ) 

Other sorting programs such as, quicksort and selection sort had been synthesized by Vargh- 
ese. Interested readers may refer to [10]. 


4 Summary and Discussion 

Even after a decade of research on software engineering the productivity still remains a bot- 
tleneck. Formal method is one of many approaches proposed to solve the problem. When a 
program is synthesized with a formal method, the tedious tasks of verification and maintenance 
become some what trivial. This makes the formal synthesis very attractive. 

We have provided a formal framework for deriving logic programs from its specification. 
The derivational method takes the best aspects of both the transformational and the deductive 
approaches. The derivation uses the nested resolution which is shown to be sound for the first 
order logic. Therefore, the derived program is sound, that is, the program is implied by the 
specifications. On the other hand, since the derived program not always imply the specification, 
the derivation system is some what weak. Our framework, however, has the advantage that 
a partial program can always be derived even from a partial specification. Note here that 
a complete specification is required to derive programs constructively using theorem proving 
approaches. 

In this paper we have derived several sorting programs from the same specification set. 
Different sorting programs were derived by carefully selecting transformers and transformation 
rules. As it has been described, automating the derivation is not very practical because of 
possible combinatorial explosion. This is also true with many automating programming using 
theorem proving approaches. In our recent work, we have proposed a semi automated approach 
for deriving logic programs [11]. 
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